[RNE Rewrite] fix(fetcher): make iOS resume actually append, and never cache a short file - #1365

Android downloads run on the system DownloadManager, so they continue while
the app is backgrounded or killed. iOS streamed in-process through blob-util,
which does not. Measured on device against a 314 MB file: suspending the app
tore the connection down ONE SECOND later, 43 MB in, and the server logged the
drop. For a 1-3 GB model that is the difference between a download finishing
and never finishing, and it is one of the ways a partial file appeared in the
first place.

iOS only offers background transfers through a background NSURLSession, so
this adds one, owned by the package rather than borrowed from blob-util.

The awkward part is that a background session only does DOWNLOAD tasks, which
stage into their own private file and hand it over whole at the end. There is
no partially written file to append to, so the Range-based `.partial` resume
from #1365 cannot be kept alongside it. Resume instead goes through
NSURLSession's own resume data, which is persisted next to the destination, so
it survives the app being killed and not merely suspended. Cancelling still
keeps the bytes: `cancelByProducingResumeData:` rather than a plain `cancel`.

Details that were not optional:

* The session identifier is fixed rather than per-request, because that is what
  lets iOS hand a finished transfer back to a relaunched app. It also means the
  session outlives the JS: `startDownload` therefore adopts a task already
  running for the same destination instead of starting a second one, and
  `resetDownload` (which backs `forceDownload`) cancels it, or "download it
  again" would attach to the attempt it is meant to replace.
* `discretionary` is set to NO. Background sessions otherwise let iOS defer a
  transfer on power or network grounds, which is wrong for a download the user
  just asked for.
* `cancelByProducingResumeData:` returns its data asynchronously. Without
  waiting for it, a download restarted straight after an abort read the resume
  file before it was written and started from zero; observed exactly that, then
  fixed it by having a start wait on an in-flight cancel for the same file.
* A background download task never fires `didReceiveResponse`, so there is no
  mid-transfer status any more. The completeness check from #1365 is unaffected:
  it compares the bytes on disk against the expected length.

Verified on an iPhone 16, against a server logging what it actually sent:

* Suspended at 12.8%, the transfer kept going for 129 s and 311 of 314 MB with
  no drop, then delivered completion and resolved. The control run, on the old
  path, dropped one second after suspension.
* Aborted at p=0.0793 and downloaded again: resumed at p=0.0799, and the server
  saw `Range: bytes=25134704-` (exactly 0.0799 of the file) rather than a
  second full request.

Part of #1366.

Known limitation: a transfer that finishes while the app is KILLED needs the
host app to forward `application:handleEventsForBackgroundURLSession:`. Without
it, surviving suspension still works. Left as a follow-up.

… the wire (#1368)

## Description

Overall download progress did not track the bytes actually on the wire.
It crawled, sat near zero for most of a large download, then jumped at
the end. Measured on device against a 2.5 GiB body, the old bar reported
`0.00 -> 0.20 -> 0.41 -> 0.62 -> -0.78 -> 1.00`; it now reports `0.00 ->
0.19 -> 0.39 -> 0.60 -> 0.81 -> 1.00`.

Five causes, found by logging the raw native samples:

1. **Android lost the top bits of the byte counter past 2 GB.**
blob-util reads DownloadManager's `COLUMN_BYTES_DOWNLOADED_SO_FAR` with
`getInt`
([ReactNativeBlobUtilReq.java:213](https://github.com/RonRadtke/react-native-blob-util/blob/master/android/src/main/java/com/ReactNativeBlobUtil/ReactNativeBlobUtilReq.java#L213)),
so JS receives the low 32 bits of a 64-bit counter as a signed int. On
device the sample after `1668939776` was `-2057109504`: really
2,237,857,792 bytes, 83% of the file, reported as -77%. `Math.min(sum /
total, 1)` had no lower bound to stop it. `COLUMN_TOTAL_SIZE_BYTES` uses
`getLong`, so only the numerator was affected. The counter only grows,
so the wraps are counted and the high bits restored.
2. **A single failed HEAD re-weighted every file.** Byte weighting
applied only when every HEAD succeeded; one failure dropped all files to
equal weighting, so a tokenizer counted as much as a 3 GB model. Weights
are now per file, and an unmeasured file corrects itself once its
transfer reports a real length.
3. **A finished file stayed short of its own size.** blob-util throttles
progress events and DownloadManager is polled, so the final chunk lands
between samples. A 711 KB file next to the 2.5 GiB one contributed zero
for the whole run. Each file now reports its on-disk size once it lands.
4. **Cached files paid a HEAD they did not need.** The cache was
consulted inside `downloadUrl`, after `download()` had already HEADed
every URL for weighting. A fully cached config cost one round trip per
file (2 of 2 on the warm run measured here, now 0).
5. **iOS sampled a third as often.** 20 callbacks per file against
Android's 100, so a multi-GB download moved in 5% steps. Also, a
response with no `Content-Length` reports `written: 0, total: -1` on a
timer, dragging that file back to zero, and a resume started the bar at
zero instead of at the bytes already on disk.

The bar is also monotonic now: learning a weight mid-flight shifts the
denominator, and a restarted transfer genuinely loses ground.

### Introduces a breaking change?

- [ ] Yes
- [x] No

### Type of change

- [x] Bug fix (change which fixes an issue)
- [ ] New feature (change which adds functionality)
- [ ] Documentation update (improves or adds clarity to existing
documentation)
- [ ] Other (chores, tests, code style improvements etc.)

### Tested on

- [x] iOS
- [x] Android

### Testing instructions

Progress only misbehaves visibly past 2 GB, so the file has to be larger
than that. Downloading one over the internet takes too long to iterate
on, so serve it locally:

1. Run a server that streams a >2 GB body with a correct
`Content-Length` and `Accept-Ranges` (any static 2.5 GiB file works).
2. `adb reverse tcp:8099 tcp:8099`, so the device reaches it at
`http://127.0.0.1:8099/big.bin` over the cable rather than over wifi.
3. Call `download('http://127.0.0.1:8099/big.bin', { forceDownload:
true, onProgress: console.log })` and watch the values.

Before this change the reported value goes negative shortly after 2 GB;
after it, it rises monotonically. For point 4, add a second small URL,
run once to populate the cache, then run again without `forceDownload`
and count the HEAD requests reaching the server.

### Related issues

Part of #1366. Stacked on #1365, which it uses the expected-length
plumbing from.

### Checklist

- [x] I have performed a self-review of my code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have updated the documentation accordingly
- [x] My changes generate no new warnings

### Additional notes

Point 5 is now verified on an iPhone 16 as well: a run whose `.partial`
already held 8.5% of the file started the bar at `p=0.0852` instead of
at zero, and produced 107 progress samples in smooth ~0.9% steps rather
than the 20 the old count allowed.

Point 1 is an upstream blob-util bug. Worth reporting there, but the
workaround here is cheap and does not depend on a fix landing.

The two remaining parts of #1366, iOS background downloads and
large-file speed, follow in separate PRs.

Android downloads run on the system DownloadManager, so they continue while
the app is backgrounded or killed. iOS streamed in-process through blob-util,
which does not. Measured on device against a 314 MB file: suspending the app
tore the connection down ONE SECOND later, 43 MB in, and the server logged the
drop. For a 1-3 GB model that is the difference between a download finishing
and never finishing, and it is one of the ways a partial file appeared in the
first place.

iOS only offers background transfers through a background NSURLSession, so
this adds one, owned by the package rather than borrowed from blob-util.

The awkward part is that a background session only does DOWNLOAD tasks, which
stage into their own private file and hand it over whole at the end. There is
no partially written file to append to, so the Range-based `.partial` resume
from #1365 cannot be kept alongside it. Resume instead goes through
NSURLSession's own resume data, which is persisted next to the destination, so
it survives the app being killed and not merely suspended. Cancelling still
keeps the bytes: `cancelByProducingResumeData:` rather than a plain `cancel`.

Details that were not optional:

* The session identifier is fixed rather than per-request, because that is what
  lets iOS hand a finished transfer back to a relaunched app. It also means the
  session outlives the JS: `startDownload` therefore adopts a task already
  running for the same destination instead of starting a second one, and
  `resetDownload` (which backs `forceDownload`) cancels it, or "download it
  again" would attach to the attempt it is meant to replace.
* `discretionary` is set to NO. Background sessions otherwise let iOS defer a
  transfer on power or network grounds, which is wrong for a download the user
  just asked for.
* `cancelByProducingResumeData:` returns its data asynchronously. Without
  waiting for it, a download restarted straight after an abort read the resume
  file before it was written and started from zero; observed exactly that, then
  fixed it by having a start wait on an in-flight cancel for the same file.
* A background download task never fires `didReceiveResponse`, so there is no
  mid-transfer status any more. The completeness check from #1365 is unaffected:
  it compares the bytes on disk against the expected length.

Verified on an iPhone 16, against a server logging what it actually sent:

* Suspended at 12.8%, the transfer kept going for 129 s and 311 of 314 MB with
  no drop, then delivered completion and resolved. The control run, on the old
  path, dropped one second after suspension.
* Aborted at p=0.0793 and downloaded again: resumed at p=0.0799, and the server
  saw `Range: bytes=25134704-` (exactly 0.0799 of the file) rather than a
  second full request.

Part of #1366.

Known limitation: a transfer that finishes while the app is KILLED needs the
host app to forward `application:handleEventsForBackgroundURLSession:`. Without
it, surviving suspension still works. Left as a follow-up.

Android downloads run on the system DownloadManager, so they continue while
the app is backgrounded or killed. iOS streamed in-process through blob-util,
which does not. Measured on device against a 314 MB file: suspending the app
tore the connection down ONE SECOND later, 43 MB in, and the server logged the
drop. For a 1-3 GB model that is the difference between a download finishing
and never finishing, and it is one of the ways a partial file appeared in the
first place.

iOS only offers background transfers through a background NSURLSession, so
this adds one, owned by the package rather than borrowed from blob-util.

The awkward part is that a background session only does DOWNLOAD tasks, which
stage into their own private file and hand it over whole at the end. There is
no partially written file to append to, so the Range-based `.partial` resume
from #1365 cannot be kept alongside it. Resume instead goes through
NSURLSession's own resume data, which is persisted next to the destination, so
it survives the app being killed and not merely suspended. Cancelling still
keeps the bytes: `cancelByProducingResumeData:` rather than a plain `cancel`.

Details that were not optional:

* The session identifier is fixed rather than per-request, because that is what
  lets iOS hand a finished transfer back to a relaunched app. It also means the
  session outlives the JS: `startDownload` therefore adopts a task already
  running for the same destination instead of starting a second one, and
  `resetDownload` (which backs `forceDownload`) cancels it, or "download it
  again" would attach to the attempt it is meant to replace.
* `discretionary` is set to NO. Background sessions otherwise let iOS defer a
  transfer on power or network grounds, which is wrong for a download the user
  just asked for.
* `cancelByProducingResumeData:` returns its data asynchronously. Without
  waiting for it, a download restarted straight after an abort read the resume
  file before it was written and started from zero; observed exactly that, then
  fixed it by having a start wait on an in-flight cancel for the same file.
* A background download task never fires `didReceiveResponse`, so there is no
  mid-transfer status any more. The completeness check from #1365 is unaffected:
  it compares the bytes on disk against the expected length.

Verified on an iPhone 16, against a server logging what it actually sent:

* Suspended at 12.8%, the transfer kept going for 129 s and 311 of 314 MB with
  no drop, then delivered completion and resolved. The control run, on the old
  path, dropped one second after suspension.
* Aborted at p=0.0793 and downloaded again: resumed at p=0.0799, and the server
  saw `Range: bytes=25134704-` (exactly 0.0799 of the file) rather than a
  second full request.

Part of #1366.

Known limitation: a transfer that finishes while the app is KILLED needs the
host app to forward `application:handleEventsForBackgroundURLSession:`. Without
it, surviving suspension still works. Left as a follow-up.